-
-
Notifications
You must be signed in to change notification settings - Fork 176
uefi-raw: improve convenience of net types #1699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
2b8f102
to
85838ce
Compare
For the record. Starting Friday, I'll be on vacation until July 30th. My plan is to program-detox for the whole period 😀 Restarting the work afterwards |
I'm unsure how I could fix the rustdoc error best. I want the documentation of the However: making the module public allows to import the same types from |
What if we removed the module doc and instead added this information to the individual types? The module doc is basically saying "you can convert between /// An IPv4 internet protocol address.
///
/// This type can be converted to and from [`core::net::Ipv4Addr`] using the [`From`] trait.
|
c2d44b0
to
24d5443
Compare
Yeah, good idea, why not :) What do you think about the latest state? |
411d16e
to
f2b5198
Compare
Generally looks good, but I haven't reviewed the details yet. Could you open a PR that just does the copy-paste move of stuff to a new module first? That should be very quick to review and merge, and then it won't get mixed in with the other changes. (I realize it's already broken down that way by commit, but there are still a lot of changes in commit 870aced that I would like to review more thoroughly, and it'll be easier for me if the module-move has already been merged.) |
aa1b362
to
4261a10
Compare
This will help in the following to better distinct between all the types from core::net (Std prefix) and EFI (no prefix).
should be much easier to review now |
- added missing conversions between core::net types and the uefi-raw net types - added missing conversions for "typical byte arrays"
@@ -83,19 +119,65 @@ pub union IpAddress { | |||
} | |||
|
|||
impl IpAddress { | |||
/// Construct a new zeroed address. | |||
#[must_use] | |||
pub const fn new_zeroed() -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about an associated const
instead of a function?
pub const ZERO: Self = Self { addr: [0; 4] };
@@ -24,19 +32,32 @@ impl Ipv4Address { | |||
} | |||
} | |||
|
|||
impl From<core::net::Ipv4Addr> for Ipv4Address { | |||
fn from(ip: core::net::Ipv4Addr) -> Self { | |||
impl From<StdIpv4Addr> for Ipv4Address { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I guess this is a personal preference thing, but I don't think it's clearer to introduce type aliases for the core::net types. core::net::
isn't that long to write out, and is more explicit.
v4: Ipv4Address(ip_addr), | ||
} | ||
pub const fn new_v4(octets: [u8; 4]) -> Self { | ||
// Initialize all bytes to zero first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you say more about why this is desired? Perhaps a specific example of code where it would be useful to have this property.
|
||
/// Returns a raw pointer to the IP address. | ||
#[must_use] | ||
pub const fn as_ptr(&self) -> *const Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a method is needed when it's just returning a pointer to self
, instead the caller can write &raw addr
/&raw mut addr
(those operators were stabilized in 1.82)
@@ -158,9 +278,10 @@ impl From<[u8; 6]> for MacAddress { | |||
} | |||
} | |||
|
|||
impl From<MacAddress> for [u8; 6] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was removing MacAddress -> [u8; 6]
intentional?
|
||
/// Tries to interpret the MAC address as normal 6-byte MAC address, as used | ||
/// in ethernet. | ||
pub fn try_into_ethernet_mac_addr(self) -> Result<[u8; 6], [u8; 32]> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to make an assumption about zero being invalid, but is that true? If so, let's point to relevant documentation. If not, let's drop this method.
/// IPv4 address. | ||
/// | ||
/// # Safety | ||
/// Callers must be sure that all underlying bytes were initialized. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This is a bit ambiguous. "all underlying bytes" could be read as "all bytes in the type", but that's not required for ipv4. Maybe something like: "Callers must ensure that the v4
field is valid if is_ipv6
is false, and that the v6
field is valid if is_ipv6
is true"
/// # Safety | ||
/// Callers must be sure that all underlying bytes were initialized. | ||
#[must_use] | ||
pub unsafe fn into_std_ip_addr(self, is_ipv6: bool) -> StdIpAddr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Should this be into_core_ip_addr
? I'm not sure if there's an existing ecosystem convention either way, just want to make clear to end users that this method works in a no_std
env.
This prepares my vision for #1575, a split-out from #1645.
This adds much more convenience to the network types in
uefi-raw
, better integrating them withcore::net
types but also "typical" workflows. This "higher-level" logic is still low-level enough that I think it is perfectly fine to keep it. It will also not hinder Rust-based UEFI implementations.Steps to Undraft
Checklist